The present invention addresses the problem of determining how much transport capacity (e.g., in terms of bandwidth) should be provided to a transport facility, e.g., a link in a telecommunications network. Although this problem is one of general applicability in the telecommunications field, it is more specifically illustrated herein in the context of determining how much transport capacity should be provided to a so-called IuB—a wireless network infrastructure facility that hauls voice and data traffic from cell sites to radio network controllers, which manages radio resources. This specification uses the word “link” to refer to any transport facility whose transport capacity is to be determined.
There are two competing considerations when determining how much transport capacity should be provided to a network link. On the one hand, one wants to satisfy the quality metrics promised by the network operator to customers for all kinds of traffic—including, for example, voice, data, and video. Under-engineering of a link, i.e., not providing it with enough bandwidth to meet those metrics, can create serious customer dissatisfaction stemming from traffic congestion. At the same time, link capacity provisioning is a capital intensive undertaking, and over-engineering of transport facilities, i.e., providing more bandwidth than is necessary to ensure that quality metrics are met, can easily overrun the cost of operations and make the an overall operation unprofitable. It is very desirable, therefore, to have link sizing, or “dimensioning,” be carried out in a way that balances these two aspects.
In addition, calculations for transport facilities such as IuBs are often done on projected values of voice/data/video demands for planning purposes, and it is important that the dimensioning be at least somewhat resilient to variations from the traffic assumptions to avoid unexpected results.
Until now, the above problem has been solved in the prior art by methods that can be broadly classify into two categories. The first category treats all traffic as “call” type, while taking into account various performance (blocking) criteria utilizing a multi-dimensional Erlang-B (often referred to as Kaufman-Roberts algorithm) modeling approach or its variants. This is a quite straightforward approach but tends to over-engineer link capacities significantly, especially at larger data loads. With the recent explosion of data communication over wireless (3G and beyond), this approach is not financially viable.
The second category is somewhat more refined. Here the analysis separates data traffic into elastic data traffic (data traffic which is not time sensitive, such as file transfers) and stream, or streaming, data traffic (data traffic which is at least somewhat time sensitive, such as video where some buffering is possible) and appropriate queuing models are employed to size the link Although methodologies in this category exploit the statistical properties of data to realize so-called “statistical multiplexing gain,” they allow one to meet quality metrics only in an average sense. That is, they are only able to assure a customer that the customer's average throughput will meet some stated bit rate (e.g., 700 Kbps). Achieving that particular goal may be of little value to a customer whose throughput happens to be below (and possibly significantly below) the average during a given session. Indeed, customers' experiences can vary widely. For example, during a ten-minute session, a throughput of 100 Kbps for five minutes and a throughput of 1300 Kbps for the remaining five minutes will result in a throughput 700 Kbps on average, but can result in substantial customer dissatisfaction due to the poor throughput during the first five minutes. As a matter of fact, the customer may get irritated during the 100 Kbps session and disconnect himself/herself from the network forcefully by initiating a new session, thus may not even see the 1300 Kbps session. In addition, this approach tends to make the utilization levels of a transport facilities very high (close to 100% at large loads), which means there is no room to accommodate forecast variations (on the upside) or changes in traffic assumptions. As a greater number of applications is being introduced, (especially with the advent of devices like the iPhone®), the traffic mix (hence the statistics) can vary unexpectedly, posing problems with this type of link sizing approach.